[WIP] arch: riscv: smp: add PLIC-based IPI #81260
Conversation
The currently IPI implementation assumes that CLINT exists in the system, however, that might not be the case as IPI can be implemented with PLIC that supports software-triggering as well, such as the Andes NCEPLIC100. Refactor the CLINT-based IPI implementations into `ipi_clint.c`, and create Kconfig that selects the CLINT implementation when `sifive-clint0` exists and enabled, otherwise default to `RISCV_SMP_IPI_CUSTOM` which allows OOT implementation. This also makes way for the upstreaming of non-clint IPI implementation later. Signed-off-by: Yong Cong Sin <[email protected]>
Add PLIC-based IPI implementation. Signed-off-by: Yong Cong Sin <[email protected]>
ycsin
force-pushed
the
pr/riscv-ipi-plic-alt
branch
from
d8ea9b7 to
998cfd5
Compare
ycsin
requested review from
cfriedt,
fkokosinski,
jimmyzhe,
luchnikov and
npitre
ycsin
added
area: RISCV
npitre
left a comment
npitre
left a comment
There was a problem hiding this comment.
Normally, the device tree should contain stuff that describes the hardware
in a generic way. Here, the fact that FPU and scheduling are assigned IRQ
values in DT is too much software implementation details to live in DT. You
should see the device tree information as something that any operating
system may consume, and another OS implementation could opt to do things
differently,. There are exceptions already, but we should refrain from
adding more of them.
You should consider only listing in the DT all those IRQs that are available
for IPI usage and do the assignment in the source code instead.
|
CI failure is unrelated and fixed by #81367 |
|
DT usage still needs fixing per my earlier comment.
|
Sure, I remember I met some difficulties to generate The FPU part also requires the following PLIC functions that I have yet to work on:
|
|
You may take the simple route and have the device tree simply expose
some IRQ range. Then the C code can just hardcode offsets within that
range.
|
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
2 participants
See #81215
See #81256
FPU_SHARINGdepends onriscv_plic_irq_is_pending()&riscv_plic_irq_clear_pending()